Day 30 WordPress 的 PHP 程式碼撰寫標準與本地開發環境建置

第 12 屆 iThome 鐵人賽

DAY 30

自我挑戰組

WordPress 客製化從 0 開始系列第 30 篇

12th鐵人賽 wordpress php coding standard

Eric 桓桓

2020-10-01 21:53:53

2384 瀏覽

分享至

大家好，我是 Eric。

今天來到《WordPress 客製化從 0 開始》的最終章，要來跟大家分享 PHP 的程式碼撰寫標準以及開發環境的說明。

PHP 程式碼撰寫標準

根據 WordPress 的開發人員手冊，我們可以看到 WordPress 的程式碼撰寫標準，主要是根據 Pear 的標準加以改編。

可讀性優先

制定標準的目的，在於可以讓其他人快速理解你的程式碼，因此比起聰明的作法，開發人員應該更重視可讀性。許多 WordPress 的程式碼撰寫標準，都是以可讀性為最高指導原則。

/* 比較聰明的寫法 */
isset( $var ) || $var = some_function();
/* 可讀性比較高的寫法 */
if ( ! isset( $var ) ) {
    $var = some_function();
}

單雙引號

雖然 PHP 本身沒有對單雙引號有限制，但在 WordPress 的程式碼中，原則上使用單引號 '，但有需要運算的時候，則需要使用雙引號 "，最主要是為了避免使用反斜線 \ 作為跳脫的方法：

/* 一般情況下，使用單引號 */
echo '<a href="/static/link" title="Yeah yeah!">Link name</a>';
/* 字串中包含變數時，則用雙引號 */
echo "<a href='$link' title='$linktitle'>$linkname</a>";

間隔的使用

和 JavaScript 中一樣，應使用 tab 來進行縮排。唯一的例外，是為了提升可讀性，在行間透過半形空格進行手動縮排例如：

$args = array(
    'post_type'      => 'post',
    'posts_per_page' => 10,
    'post__in'       => array( 1, 2, 3, ),
);

而在陣列當中，如果是具有屬性與屬性值的情況，除非只有一個屬性，否則每個屬性都要獨立一行。

條件判斷

在使用 if ... else 或是 while() 的時候，會進行條件判斷，這時候條件判斷有 2 點需要注意：

結果在前，譬如 if ( true === something() ) 而非 if ( something() === true )。
利用三元運算子 (ternary operator) 做判斷時，判斷式應該判斷是否為 true 而非判斷是否為 false。舉例來說，並且不要使用縮寫 ( $value = $判斷 ?: $不符判斷結果; )。

程式碼安全

為了確保程式碼安全，在程式碼中插入 HTML 屬性時，應該要藉由 esc_attr 來跳脫不安全的字串。如果是網址的話，則應用 esc_url 處理。

eval() 與 create_function() (後者已於 PHP 7.2 被廢除) 因為會將字串視為 PHP 程式執行，因此強烈不建議使用。關於 eval() 可能造成的安全性問題，可以參考這篇 StackOverflow 討論，其中說明 eval() 最大的風險在於「欠缺經驗的開發者誤用」。只有在「必要的情況」下，當 eval() 是唯一的解決手段時，才可以考慮使用 (聽起來就像刑法)，而什麼是必要的情況，這篇 StackOverflow 討論提到：

譬如要根據使用者的輸入值，建立複雜的運算式時；或是將物件狀態序列化為字串，便於儲存、傳遞、以及事後重構時。

舉例來說，Code Snippets 便符合上列情形的使用情境。

開發環境建置

我在一開始學習 HTML 時，我是跟著 Coursera 上的這門課程來建置我的系統環境。
在第一次的網站專案中，我是在本地直接將程式碼撰寫後，透過 FTP 去覆蓋原本的檔案，再重新整理頁面，看修改後的結果，接下來再回到本機修改。這是一個在新手階段很容易犯的錯，這種作法會使你無法掌握開發的過程，導致修改後發生錯誤時，難以追蹤造成錯誤的原因。
直到我看到這篇文章。
簡單來說，就是將開發環境分為本地 (local)、測試 (staging) 與正式 (living) 環境。

本地環境建置

每個人的開發習慣不同，會有不同的開發環境。如果是第一次建置本地環境的人，你的本地環境需要注意以下 4 點：

版本控制：為了要讓開發流程可以追蹤，因此一定要對版本控制 (version control) 有基本理解，譬如 Git，詳情可以參考這系列的鐵人賽文章。因為現在 GitHub 讓免費帳戶能夠建立私有儲存庫，因此我目前都以 GitHub 為遠端儲存庫。
編輯器：在編輯器的選擇上，PHP 與 HTML、CSS、JavaScript 都可以直接透過記事本編輯。但是為了要替程式碼加上醒目提示 (highlight，不是「高亮」)，因此一般來說會透過較進階的編輯器，如 Visual Studio Code、Sublime Text 或 Atom。
本地主機：執行 WordPress 需要 PHP + MySQL 的環境，為了在本地能夠執行 PHP + MySQL，除了自己從頭建置環境外，也可以透過套件如 WAMP Server (Windows)、MAMP (MacOS) 來部署本地環境。另外，社群夥伴 Oberon 也曾分享專門用於 WordPress 的本地環境套件 Valet，如果是對命令列介面 (command line interface) 較熟悉的開發人員可以嘗試。
套件管理程式：在開發中，可以透過 NPM 的套件 (有關 NPM 的主題，可以參考這則鐵人賽文章) 來編譯 SCSS、最小化靜態資源、檢查程式碼品質。
WP-CLI：主要是用來建立本地化專案的 .pot 檔用。

以我個人為例，我的本地環境便是透過 Git 進行版本控制、Visual Studio Code 為主要編輯器 (同時把它當成 MacOS 的記事本來用)、主機是 MAMP Pro、套件管理則有 NPM。此外，因為我也有管理中的本地化專案，因此我也安裝了 WP-CLI 與 Poedit。

測試環境與正式環境

關於正式環境，如果你是自行租用虛擬私有伺服器 (VPS)，會需要自行建置 PHP + MySQL 的環境，可以參考網路上提供的堆疊程式碼 (stack scripts)，如 lnmp.org 或針對 WordPress 進行最佳化調校的 Webinoly。
如果不想要花時間研究主機部署，也可以直接透過共享空間 (shared hosting) 作為正式環境，並可以租用規格較低的空間做測試環境。

結語

終於寫完了 30 天的鐵人賽。在這 30 天中，把過去藉由 WordPress 學習網站開發的種種基礎知識整理了一遍，算是為自己截至目前為止的學習歷程做一個註解。雖然 30 天的鐵人賽已經結束，但會將這 30 天下來培養的寫作習慣繼續延續。這次鐵人賽的文章，我有部分是參照自己網站上的內容，接下來我也會將這裡的文章整理後，重新發布在我的網站上。
WordPress 是一個大坑，雖然可以在 5 分鐘建造出一個網站的雛形，但從建立雛形到實際結案，其實還包含許多需要客製化的過程。學習 WordPress 客製化除了掌握程式的基本知識外，如何透過不同外掛的組合技，達到想要的效果。而透過 WordPress 的短代碼機制，以及勾點機制，讓開發者可以在其他開發者既有的成果上，擴展更多的功能。
今天正好是特別的日子，祝大家中秋節愉快。第 12 屆鐵人賽，Eric 畢業。